The multi-threaded DecoderComposite.decode submitted one task per
decoder per row block, running all decoders concurrently. This broke
the ordering dependency between decoders: recode-on-output reads the
category indexes written by the dummycode decoder, so when the recode
task raced ahead it read unwritten cells and produced null or the raw
index instead of the original value.

Parallelize over row blocks instead, running all decoders in order
within each block via the sequential block decode. Also short-circuit
to the single-threaded path when k <= 1.

Fixes order-dependent failures in TransformFrameEncodeDecodeTest and
TransformFrameEncodeColmapTest (dummycode single-node/hybrid) that
surfaced once transformdecode started using the parallel decode path.

…isions

Re-enable the betterIfDecompressed gate in CLALibRightMultBy so the
decompressing right-multiply path stays reachable, while still excluding
ASDC/ASDCZero column groups from forced decompression.

Add targeted and end-to-end tests covering the recently tuned paths:
- CLALibMMChainTest: the public CLALibTSMM.leftMultByTransposeSelf overload
  (wide/narrow/uncompressed/empty/reuse/null) and the XtXv mm-chain fast
  path, including a tile-then-recompress wide-chain case.
- CLALibRightMultBySDCTest: right multiply on ASDC/ASDCZero inputs is not
  forced to decompress, single-threaded and parallel.
- DecoderCompositeTest: parallel and single-thread composite decode,
  exercising the dummycode+recode ordering dependency.
- SparkTransitiveExecTypeTest with DML scripts: UnaryOp/BinaryOp/Hop
  transitive Spark exec-type pulling under a constrained memory budget.
- CompressedTestBase: two parameterized e2e cases that validate the TSMM
  overload and the wide XtXv fast path against uncompressed results across
  all compression configurations.

…e test

Make the spark-specific decision refinement consistent between UnaryOp
and BinaryOp:
- UnaryOp: restore the input-is-not-checkpoint and single-parent guards,
  and drop the redundant `_etype != ExecType.SPARK` clause
- BinaryOp: use the shared hasSparkOutput() helper instead of an inline
  optFindExecType() == SPARK check

Add a compilation-verification test suite under component/compile that
compiles a DML script into a runtime program and inspects instruction
exec types without executing. CompilerTestBase provides the compile and
plan-inspection helpers; SparkTransitiveExecTypeCompileTest verifies a
CP-by-estimate unary on a Spark-resident input is pulled into Spark only
when it is the sole consumer.

…nt nits

Align the unary transitive Spark exec-type refinement with BinaryOp and
clean up the new helpers introduced for the decision refresh:

- Gate the UnaryOp transitive pull on the transitive flag so
  ALLOW_TRANSITIVE_SPARK_EXEC_TYPE acts as a real kill-switch for both
  unary and binary pulls. Default is true, so default behavior is
  unchanged; disabling the flag now keeps a pullable unary op in CP.
- Rename Hop.isScalarOrVectorBellowBlockSize to isScalarOrVectorBelowBlockSize
  (spelling) and parenthesize the row/col clauses symmetrically.
- Drop the unused k parameter from the private CLALibTSMM.addCorrectionLayer
  overload.
- Simplify the redundant "v1 == true" in BinaryOp and fix a misleading
  comment on the disallowed-ops guard.
- Add flag-off compile tests proving the kill-switch keeps an otherwise
  pullable unary and binary op in CP.

Shorten redundant inline comments added with the exec-type refinement:
drop the parenthetical on the UnaryOp transitive guard, condense the
compile-test class javadoc, and remove the noisy back-references and
duplicated assert comments in the flag-off tests.